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BGP Traffic Engineering Attribute 


Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 


Copyright (c) 2009 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents in effect on the date of 
publication of this document (http://trustee.ietf.org/license-info). 
Please review these documents carefully, as they describe your rights 
and restrictions with respect to this document. 


Abstract 


This document defines a new BGP attribute, the Traffic Engineering 
attribute, that enables BGP to carry Traffic Engineering information. 


The scope and applicability of this attribute currently excludes its 
use for non-VPN reachability information. 
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Les 


Introduction 


In certain cases (e.g., Layer-1 VPNs (LIVPNs) [RFC5195]), it may be 
useful to augment the VPN reachability information carried in BGP 
with Traffic Engineering information. 


This document defines a new BGP attribute, the Traffic Engineering 
attribute, that enables BGP [RFC4271] to carry Traffic Engineering 
information. 


Section 4 of [RFC5195] describes one possible usage of this 
attribute. 


The scope and applicability of this attribute currently excludes its 
use for non-VPN reachability information. 


Procedures for modifying the Traffic Engineering attribute, when 
re-advertising a route that carries such an attribute, are outside 
the scope of this document. 

Specification of Requirements 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


Traffic Engineering Attribute 


The Traffic Engineering attribute is an optional, non-transitive BGP 
attribute. 


The information carried in this attribute is identical to what is 
carried in the Interface Switching Capability Descriptor, as 


specified in [RFC4203] and [RFC5307]. 


The attribute contains one or more of the following: 
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0 1 2 3 
01234567890123456789012345678<9021 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Switching Cap Encoding | Reserved 
+-+-4-4+-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4 
| Max LSP Bandwidth at priority 0 | 
+-+-4-4+-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4 
| Max LSP Bandwidth at priority 1 
4+-+-4-4+-4-4+-4-4+-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4 
| Max LSP Bandwidth at priority 2 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Max LSP Bandwidth at priority 3 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Max LSP Bandwidth at priority 4 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Max LSP Bandwidth at priority 5 | 
+-+-4-4+-4-4+-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4 
| Max LSP Bandwidth at priority 6 | 
4+-+-4-4+-4-4+-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4 
| Max LSP Bandwidth at priority 7 
4+-+-4-4+-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4+-4-4-4+ 

Switching Capability specific information 
(variable) 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+ — 


The Switching Capability (Switching Cap) field contains one of the 
values specified in Section 3.1.1 of [RFC3471]. 


The Encoding field contains one of the values specified in Section 
3.1.1 of [RFC3471]. 


The Reserved field SHOULD be set to 0 on transmit and MUST be ignored 
on receive. 


Maximum LSP (Label Switched Path) Bandwidth is encoded as a list of 
eight 4-octet fields in the IEEE floating point format [IEEE], with 
priority 0 first and priority 7 last. The units are bytes (not 
bits!) per second. 


The content of the Switching Capability specific information field 
depends on the value of the Switching Capability field. 


When the Switching Capability field is PSC-1, PSC-2, PSC-3, or PSC-4, 


the Switching Capability specific information field includes Minimum 
LSP Bandwidth and Interface MTU. 
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0 1 2 3 

O “2 39-409) Oe 7 8s 90 12 345-678 9.0 le 2 3 AD: 6 TB 9.0 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Minimum LSP Bandwidth 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Interface MTU | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Minimum LSP Bandwidth is encoded in a 4-octet field in the IEEE 
floating point format. The units are bytes (not bits!) per second. 
Interface MTU is encoded as a 2-octet integer. 


When the Switching Capability field is Layer-2 Switch Capable (L2SC), 
there is no Switching Capability specific information field present. 


When the Switching Capability field is Time-Division-Multiplex (TDM) 
capable, the Switching Capability specific information field includes 
Minimum LSP Bandwidth and an indication of whether the interface 
supports Standard or Arbitrary SONET/SDH (Synchronous Optical 

Network / Synchronous Digital Hierarchy). 


0 1 2 3 
01234567890123456789012345678<901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Minimum LSP Bandwidth 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Indication | 

+-+-+-+-+-+-+-+-+ 


Minimum LSP Bandwidth is encoded in a 4-octet field in the IEEE 
floating point format. The units are bytes (not bits!) per second. 
The indication of whether the interface supports Standard or 
Arbitrary SONET/SDH is encoded as 1 octet. The value of this octet 
is 0 if the interface supports Standard SONET/SDH, and 1 if the 
interface supports Arbitrary SONET/SDH. 


When the Switching Capability field is Lambda Switch Capable (LSC), 
there is no Switching Capability specific information field present. 


4. Implication on Aggregation 
Routes that carry the Traffic Engineering attribute have additional 
semantics that could affect traffic-forwarding behavior. Therefore, 


such routes SHALL NOT be aggregated unless they share identical 
Traffic Engineering attributes. 
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9. 


Constructing the Traffic Engineering attribute when aggregating 
routes with identical Traffic Engineering attributes follows the 
procedure of [RFC4201]. 


Implication on Scalability 


The use of the Traffic Engineering attribute does not increase the 

number of routes, but may increase the number of BGP Update messages 
required to distribute the routes, depending on whether or not these 
routes share the same BGP Traffic Engineering attribute (see below). 


When the routes differ other than in the Traffic Engineering 
attribute (e.g., differ in the set of Route Targets and/or NEXT_HOP), 
use of the Traffic Engineering attribute has no impact on the number 
of BGP Update messages required to carry the routes. There is also 
no impact when routes share all other attribute information and have 
an aggregated or identical Traffic Engineering attribute. When 
routes share all other attribute information and have different 
Traffic Engineering attributes, routes must be distributed in 
per-route BGP Update messages, rather than in a single message. 


IANA Considerations 


This document defines a new BGP attribute, Traffic Engineering. This 
attribute is optional and non-transitive. 


Security Considerations 
This extension to BGP does not change the underlying security issues 
currently inherent in BGP. BGP security considerations are discussed 
in RFC 4271. 
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